Presence services represents a group of well known network services which may be applied in various types of wireless and stationary communications networks for the main purpose of distributing information associated with a first user, typically referred to as a Presentity, to one or more other users, typically referred to as Watchers, on the condition that the Presentity is first authorizing the Watchers access to the requested Presence information. Throughout this document a Presentity, as well as a Watcher, are to be referred to as a respective user and an associated users equipment, where the user equipment is configured to provide Presence services by accessing a presence enabled communications network.
A presence service typically allows a Watcher to be informed about different states of a Presentity, such as e.g. the reachability, availability, and/or the willingness of the Presentity to communicate with other users. The presence service may also be used to indicate whether the Presentity is presently online or not and while being online, possibly also whether the Presentity is idle or busy. In addition, the presence service may give an authorized Watcher access to details of communication means and the respective capabilities of each communication means to which the Presentity is registered.
The Internet Engineering TaskForce (IETF) SIP Instant Messaging and Presence Leveraging Extensions (SIMPLE) technology is a technology which is describing one type of known Presence enabled application which is built on top of the SIP event notification framework, and which is suitable for use by different industry forums, such as e.g. Open Mobile Alliance (OMA), and the 3rd Generation Partnership Project (3GPP).
FIG. 1 is an illustration of a simplified scenario of a SIMPLE based Presence system 100 which is configured to provide Presence information about a Presentity P to a Watcher W, according to the prior art. The Presence system 100 comprise a Presence Server (PS) 101 and a Presence Server XML Document Management Server (PS XDMS) 102. As is well known in the art, PS XDMS may be configured as a function integrated with the PS, or as a separate function, interconnected with the PS.
In order to be able to allow or deny Watcher W access to its Presence information, Presentity P needs to make sure that it is updated with relevant Presence related information from PS 101, i.e. whenever an event of interest for the Presentity occurs. Therefore, Presentity P initially transmit a request to PS 101 to subscribe for relevant update information, in the present case its own Watcher information (W info), as indicated with a first step 1:1.
In another step 1:2, Watcher W, wanting to subscribe for Presence information associated with Presentity P, transmit a request to Presence Server 101, requesting for a such a subscription. PS 101 responds to the request by acquiring the authorization rules of Presentity P from PS XDMS 102, as indicated with another step 1:3. If the authorization rules comprises a rule which is valid for the request of step 1:2, PS 101 notifies Presentity P of the request, which makes a decision on whether or not to authorize the request and transmit the decision to PS XDMS 102, as indicated with another step 1:5. PS XDMS 102 then notifies PS 101 of the decision, i.e. of the updating of the authentication rule, in a step 1:6, and PS 101 notifies Watcher W of the decision in another step 1:7, after which PS 101 will be able to distribute relevant Presence information to Watcher W, in case the request was allowed by Presentity P in step 1:5.
The authorization model described above is based on the fact that the user which has the authorization responsibility also has the authority to actually perform the authorization. There are however situations when such a structure is not the most suitable one. One such situation may be e.g. when the Presentity is under aged. Another situation may be when the Presence information is associated with a plurality of Presentities.